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One  approach  to  software  assurance  is  to  use  an  annotated  language  such  as  SPARK.  For  safetg  critical  software  programs 
such  as  Unmanned  Aerial  Vehicle  flight  control  software,  the  risk  of  software  failure  demands  high  assurance  that  the  soft¬ 
ware  will  perform  its  intended function.  Using  an  example  from  work  being  done  at  the  U.S.  Air  Force  Academy,  this  arti¬ 
cle  describes  SPARK  and  the  formal process  of  proving  correctness  of  software  implementations. 


In  recent  years,  we  have  seen  small 
Unmanned  Aerial  Vehicles  (UAVs) 
emerge  onto  the  battlespace.  These  small 
UAVs,  which  weigh  less  than  50  pounds, 
carry  five  to  10  pounds  of  payload,  have 
mission  endurances  of  about  one  hour, 
and  field  missions  to  support  tactical  sur¬ 
veillance  and  reconnaissance  operations. 
As  the  number  of  missions  for  these 
small  UAVs  increases,  more  reliance  will 
be  placed  on  the  computer  systems  that 
win  control  these  aircraft.  It  is  already 
possible  for  a  computer  program  to  cre¬ 
ate  a  flight  plan  for  a  UAV  and  place  the 
craft  in  an  orbit  to  observe  an  item  of 
interest.  Flight  control  computer  pro¬ 
grams  are  safety  critical  because  errors  in 
these  programs  could  result  in  the  loss  of 
the  UAV  or  cause  damage  to  buildings 
and/ or  people  on  the  ground  [1] . 

Because  of  the  critical  nature  of  this 
software,  development  processes  that 
result  in  high-integrif  software  (software 
systems  that  have  a  very  low  probability 
of  failure)  [1]  must  be  used.  Verification 
and  validation  (V &V)  is  often  an  impor¬ 
tant  part  of  these  processes.  However, 
V&V  of  a  safety-critical  computer  pro¬ 
gram  can  consume  up  to  50  percent  of 
the  development  time  [2].  One  approach 
to  reuse  dedicated  V&V  schedule  time 
while  still  assuring  software  quality  is  to 
use  an  annotated  programming  language. 
For  example,  the  SPARK  programming 
language  and  its  associated  tools  increase 
the  quality  of  software  developed  while 


reducing  overall  development  time  [3,  4]. 
This  approach  to  software  development 
can  easily  become  a  valuable  tool  when 
dealing  with  safety-critical  systems.  The 
SPARK  language,  which  is  a  commercial 
product  available  from  Praxis  High 
Integrity  Systems',  is  ideal  for  systems 
such  as  UAV  flight  planning  software. 
The  SPARK  language  has  been  used  on 
many  successful  software  development 
projects  such  as  the  C-130J  [4]  and  is  the 
language  we  have  used  on  our  UAV  pro¬ 
ject.  SPARK  is  an  annotated  language 
similar  to  the  annotated  Ada  language  [5] 
and  the  Larch  annotated  language  for  C 
[6].  The  annotations  in  SPARK  create 
extra  work  for  the  development  team,  but 
it  has  been  shown  the  return  on  time 
investment  can  be  as  high  as  an  80  per¬ 
cent  reduction  in  testing  costs  [4]. 

This  article  briefly  discusses  the 
SPARK  programming  language  and 
development  process.  We  examine  a  safe¬ 
ty  critical  software  example  developed 
for  small  UAVs  developed  in  a  senior- 
level  computer  science  course  at  the  Air 
Force  Academy.  We  elucidate  the  SPARK 
process  by  examining  a  small  section  of 
the  UAV  control  software  dedicated  to 
orbital  control. 

Background 

SPARK  is  an  annotated  subset  of  the 
Ada  programming  language,  and  every 
SPARK  program  can  be  compiled  by  an 
Ada  compiler.  However,  SPARK  includes 


Figure  1:  SPARK  Tool  Set 
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several  restrictions  and  rules  governing 
the  use  of  various  programming  con¬ 
structs.  These  rules  not  only  serve  to 
simplify  the  V&V  process,  but  also  have 
a  secondary  benefit  of  helping  assure 
good  coding  practice.  For  example, 
SPARK  does  not  support  dynamic  alloca¬ 
tion  of  memory  so  things  such  as  point¬ 
ers  and  heap  variables  are  not  supported. 
The  use  of  GOTO  statements  is  also  not 
supported  and  there  are  restrictions  on 
EXIT  statements  in  loops.  These  rules 
and  restrictions  in  SPARK  allow  the 
developer  to  predict  the  exact  outcome 
when  the  code  is  executed.  This  predic¬ 
tion  ability  is  a  key  feature  of  SPARK. 

In  order  to  show  that  the  code  devel¬ 
oped  has  a  very  low  error  rate,  SPARK 
uses  formal,  mathematical  techniques  to 
prove  that  the  code  is  correct.  The  proof 
of  correctness  relies  on  the  mathematical 
description  of  what  is  true  before  the 
code  is  executed  and  what  is  true  after  the 
code  is  executed.  These  are  referred  to  as 
preconditions  and  postconditions,  respec¬ 
tively.  SPARK  includes  annotations  that 
allow  the  programmer  to  embed  the  pre¬ 
condition  and  postcondition  into  a  segment  of 
code  in  the  form  of  comments. 

The  proof  of  correctness  uses  a  tech¬ 
nique  that  begins  with  the  postcondition 
and  works  backward  through  a  segment 
of  code,  hoisting  the  postcondition  up 
through  the  SPARK  code  [1].  Since  the 
code  is  predictable,  it  is  possible  to  deter¬ 
mine  a  general  effect  of  each  statement 
and  to  reverse  that  effect,  working  back¬ 
ward  from  the  postcondition  toward  the 
precondition.  The  result  of  this  hoisting 
is  called  a  verification  condition  in  SPARK.  If 
it  can  be  shown  that  the  precondition  for 
the  segment  of  code  implies  the  verifica¬ 
tion  condition  developed  from  the  hoist- 
ing  process,  the  proof  of  correctness  is 
complete. 

SPARK  includes  several  tools  that 
help  with  the  proof  of  correctness.  The 
Examiner  tool  performs  the  hoisting 
operation  and  produces  a  collection  of 


September  2006 


I  0  CrossTalk  The  Journal  of  Defense  Software  Engineering 


Report  Documentation  Page 


Form  Approved 
0MB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number. 


1.  REPORT  DATE 

SEP  2006 

2.  REPORT  TYPE 

3.  DATES  COVERED 

00-00-2006  to  00-00-2006 

4.  TITLE  AND  SUBTITLE 

5a.  CONTRACT  NUMBER 

When  Computers  Fly,  It  Has  to  Be  Right:  Using  SPARK  for  Flight 

Control  of  Small  Unmanned  Aerial  Vehicles 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

U.S.  Air  Force  Academy, Department  of  Computer  Science, 2354  Fairchild 
DR  STE  6G101,USAF  Academy, CO, 80840 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distrihution  unlimited 

13.  SUPPLEMENTARY  NOTES 

CROSSTALK  The  Journal  of  Defense  Software  Engineering  September  2006 

14.  ABSTRACT 

15.  SUBJECT  TERMS 

1 

1  ^ 

16.  SECURITY  CLASSIFICATION  OF: 


a.  REPORT 

unclassified 


b.  ABSTRACT 

unclassified 


c.  THIS  PAGE 

unclassified 


17.  LIMITATION  OF 
ABSTRACT 

Same  as 
Report  (SAR) 


18.  NUMBER 
OF  PAGES 

5 


19a.  NAME  OF 
RESPONSIBLE  PERSON 


Standard  Form  298  (Rev.  8-98} 

Prescribed  by  ANSI  Std  Z39-18 


When  Computers  Fly,  It  Has  to  Be  Right:  Using  SPARK  for  Flight  Control  of  Small  Unmanned  Aerial  Vehicles 


verification  conditions.  The  development 
team  uses  the  Simplifier  tool  to  reduce 
the  verification  conditions  as  much  as 
possible  before  attempting  to  prove  that 
they  are  implied  by  the  precondition.  The 
Proof  Checker  tool  is  used  to  prove  that 
the  verification  conditions  imply  the  pre¬ 
condition  for  a  segment  of  code. 

Figure  1  shows  the  process  used  by  a 
software  developer.  The  developer  is 
responsible  for  annotating  the  code  with 
preconditions  and  postconditions.  The 
developer  then  executes  the  Examiner 
tool  on  the  annotated  SPARK  code,  and 
the  Examiner  returns  the  verification  con¬ 
ditions.  The  developer  then  executes  the 
Simplifier  tool  on  the  verification  condi¬ 
tions,  and  the  Simplifier  returns  the  sim¬ 
plified  verification  conditions.  The  devel¬ 
oper  then  executes  the  Proof  Checker  on 
the  verification  conditions  to  see  if  the 
tool  can  build  a  proof  of  program  cor¬ 
rectness  automatically.  If  such  a  proof 
cannot  be  built,  then  the  developer 
attempts  to  build  a  proof  manually.  In  this 
situation,  either  the  code  is  incorrect  or 
the  approach  to  constructing  such  a  proof 
is  insufficient.  An  incomplete  proof  does 
not  necessarily  mean  that  the  code  is 
incorrect,  but  a  complete  proof  does 
mean  the  code  is  correctly  implemented. 

The  burden  placed  on  the  developer 
is  to  build  correct  preconditions  and 
postconditions,  as  well  as  correct  code.  If 
a  proof  cannot  be  built  automatically  for 
the  code,  then  the  developer  will  also 
need  to  examine  the  code  or  the  verifica¬ 
tion  conditions  to  see  if  a  proof  can  be 
built  manually.  This  may  seem  like  an 
undue  burden  on  the  developer,  but  the 
return  on  this  investment  can  be  as  much 
as  an  80  percent  reduction  in  costs  during 
the  testing  phase  [4]  due  to  the  fact  that 
the  code  being  developed  is  provably  cor¬ 
rect  while  being  built. 

It  should  be  noted  that  since  the  pre¬ 
conditions  and  postconditions  are  writ¬ 
ten  by  the  code  developer,  they  are  sub¬ 
ject  to  human  error.  Therefore,  these  pre¬ 
conditions  and  postconditions  should  be 
reviewed  and  verified  by  a  separate  soft¬ 
ware  development  team.  This  moves  the 
review  process  to  a  higher  level  of 
abstraction  since  the  development  team 
is  now  reviewing  general  mathematical 
preconditions  and  postconditions  instead 
of  pages  of  code  written  in  a  program¬ 
ming  language. 

In  the  following  section,  we  describe 
a  small  example  that  shows  the  SPARK 
development  process  in  action.  This 
example  also  highlights  how  the  SPARK 
tools  detect  errors.  At  the  U.S.  Air  Force 
Academy,  we  use  SPARK  to  develop 


code  in  the  senior-level  software  engi¬ 
neering  course  as  we  develop  code  to 
build  flight  plans  for  UAVs. 

UAV  Situational 
Awareness  Tool 

In  order  to  improve  the  situational  aware¬ 
ness  of  a  commander  during  a  crisis  situa¬ 
tion,  we  have  developed  the  UAV 
Situational  Awareness  Tool  (UAVSAT)  [7]. 
This  year  we  have  ported  UAVSAT  to 
Google  Earth^,  which  shows  the  location  of 
the  UAV  in  three  dimensions  along  with  a 
near  real-time  video  feed  from  the  UAV. 


The  UAVSAT  tool  also  provides  the  com¬ 
mander  the  ability  to  select  a  location  on  the 
map  for  the  UAV  to  orbit.  Figure  2  shows 
how  the  commander  selects  a  location  on 
Google  Earth  and  indicates  where  the  UAV 
should  orbit.  To  position  the  UAV  and  gim- 
baled  camera,  the  software  we  developed 
automatically  calculates  the  optimal  orbit 
altitude  and  radius  to  position  it  in  the  cor¬ 
rect  orbit  to  stare  at  the  location  selected  by 
the  commander.  The  software  builds  a  new 
flight  plan  for  the  UAV  in  order  to  transi¬ 
tion  it  from  its  current  latitude  and  longi¬ 
tude  to  an  optimal  orbit  radius  and  altitude. 
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Using  SPARK  for  Flight 
Control 

Since  the  orbit  flight  plan  for  the  UAV  is 
built  automatically  by  UAVSAT,  it  is 
imperative  to  calculate  the  correct  altitude 
and  radius  for  the  UAV’s  orbit.  If  these 
values  are  not  calculated  correctly,  the 
UAV  win  not  be  able  to  position  the  cam¬ 
era  properly  to  observe  the  area  of  inter¬ 
est.  If  these  calculations  include  flight  crit¬ 
ical  phases,  such  as  terrain  avoidance  or 
aircraft  spacing,  errors  in  the  calculations 
could  cause  loss  of  the  aircraft  or  destruc¬ 
tion  of  objects  on  the  ground.  In  order  to 
ensure  that  the  auto-orbit  calculations  are 
coded  properly,  we  are  using  SPARK  to 
verify  the  implementation. 

Figure  3  (see  page  II)  shows  which 
calculations  need  to  be  done  in  order  to 
determine  the  proper  flight  plan  for  the 
UAV.  In  the  figure,  h  is  the  altitude  of  the 
orbit,  r  is  the  radius  of  the  orbit,  and  a  is 
the  angle  of  the  gimbaled  camera.  The  lat¬ 
itude  and  longitude  of  the  orbit  location 
are  provided  to  UAVSAT  as  selected 
through  the  auto-orbit  tool  and  positioned 
by  the  commander.  To  simplify  the  orbit 


problem,  we  have  initially  fixed  the  alti¬ 
tude  of  the  orbit  at  500  feet  above  ground 
level  and  have  fixed  the  gimbal’s  angle  at 
30  degrees.  The  code  for  calculating  the 
auto-orbit  flight  plan  must  simply  deter¬ 
mine  the  radius  (r),  given  the  altitude  and 
the  gimbal  angle. 

Figure  4  depicts  the  problem  as  two 
similar  right  triangles.  The  tangent  of  the 
angle  (a)  is  equal  to  the  opposite  side  of 
the  triangle  over  the  adjacent  side  of  the 
triangle.  In  the  figure,  this  is  represented 
by  tan  (a)  =  hj  r.  Solving  for  r,  the  result  is 
r  =  h/tan  (a).  That  is,  to  calculate  the 
radius  of  the  orbit,  we  simply  divide  the 
altitude  by  the  tangent  of  a. 

In  order  for  UAVSAT  to  receive  the 
current  latitude  and  longitude  of  the  UAV 
and  also  to  upload  new  flight  plans  to  the 
UAV,  our  software  must  interface  with 
C++  code  provided  by  the  autopilot  ven¬ 
dor.  We  could  have  implemented  UAVSAT 
in  C/ C++,  but  we  wanted  to  preserve  our 
ability  to  use  the  automated  verification 
provided  by  SPARK.  We  therefore  used 
Ada  to  build  a  Dynamically  Linked  Library 
(DLL)  called  from  the  C++  code.  This 


DLL  interface  utility  is  well  documented  in 
the  Ada  Language  Reference  Manual’. 

Figure  5  shows  the  Ada_Radius  func¬ 
tion  built  in  the  DLL  interface  to  calculate 
the  radius  r  for  the  auto-orbit  utility.  Now 
the  developer  annotates  preconditions  and 
postconditions  for  the  Ada_Radius  func¬ 
tion. 

Figure  6  shows  the  specification  of  the 
Ada_Radius  function.  The  specification 
includes  the  annotations  for  the  precondi¬ 
tions  and  the  postconditions.  For  func¬ 
tions  in  SPARK,  the  postconditions  are 
annotated  by  using  the  return  annotation 
[1].  The  precondition  for  Ada_Radius 
allows  heights  greater  than  or  equal  to 
zero.  The  input  angle  is  restricted  from 
zero  to  avoid  a  potential  division  by  zero 
error.  The  postcondition  for  Ada_Radius 
expresses  the  mathematical  formula  for 
the  radius  calculation.  The  angle  is  multi¬ 
plied  by  Pi  over  180  to  convert  the  angle 
from  degrees  into  radians  as  expected  by 
the  tangent  function. 

Figure  7  shows  the  body  of  the 
Ada_Radius  function.  Since  the  precon¬ 
ditions  and  postconditions  are  defined  in 
the  specification,  no  further  annotations 
are  needed  in  the  body.  The  code  is  now 
ready  to  be  analyzed  by  the  SPARK 
Examiner.  The  developer  executes  the 
Examiner  tool  passing  in  the  Ada_Radius 
function  to  be  analyzed.  The  Examiner 
returns  the  verification  conditions,  and 
the  developer  executes  the  Simplifier, 
which  returns  the  simpUfled  verification 
conditions  shown  in  Figure  8. 

In  the  figure,  the  lines  beginning  with 
H  represent  hypotheses  and  the  line  begin¬ 
ning  with  C  represents  a  condition.  The 
symbol  ->indicates  implication.  In  this  ver¬ 
ification  condition,  HI  and  H2  are 
derived  directly  from  the  precondition  of 
Ada_Radius.  H3  is  determined  during  the 
process  of  hoisting  the  postcondition 
through  the  code  and  states  that  the 
result  of  the  tangent  function  is  restrict¬ 
ed  from  zero.  Since  the  radius  is  given  as 
hltan{a),  H3  is  avoiding  a  potential  divi¬ 
sion  by  zero.  Cl  indicates  the  final  part  of 
the  verification  condition  built  from  the 
hoisting  process.  The  code  takes  the  first 
line  of  Cl,  and  the  postcondition  takes 
the  second  line  of  Cl.  In  order  to  prove 
the  code  is  correct,  we  must  show  that 
this  implication  is  true  (i.e.  that  H1-H3 
imply  Cl).  So  far,  the  developer  has  built 
the  code  and  the  annotations.  The 
Examiner  and  Simplifier  have  built  this 
simplified  verification  condition  auto¬ 
matically  for  the  developer. 

The  next  step  is  to  attempt  to  build  a 
proof  that  this  verification  condition  is 
true.  The  developer  executes  the  Proof 


Figure  5:  Ada_Radius 

--  function  to  calculate  the  radius  in  Ada 
function  Ada_Radius  ( 

Height  :  in  Float; 

Angle  :  in  Float) 
return  Float  is 
begin 

return  (Height  /  Ada_Tangent { (3 . 14159/180 . 0) )  *  Angle); 
end  Ada_Radius ; 


Figure  6:  Specification  for  Ada_Radius 

--  function  to  calculate  the  radius  in  Ada 
function  Ada_Radius  ( 

Height  :  in  Float; 

Angle  :  in  Float) 
return  Float; 

--#  pre  (Height  >=  0.0)  and  (Angle  /=  0.0); 

--#  return  (Height/Ada_Tangent ( (3 . 14159/180 . 0 )  *  Angle)); 
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Checker  passing  in  the  simplified  verifica¬ 
tion  condition.  In  this  example,  the  Proof 
Checker  is  not  able  to  build  a  proof  and 
the  developer  must  consider  the  possibili¬ 
ty  that  the  code  is  incorrect.  Careful 
inspection  of  Cl  shows  that  the  angk  vari¬ 
able  has  been  moved  to  the  front  of  the 
expression  during  the  simplification 
process.  This  inadvertently  highlights  a 
discrepancy  between  the  code  and  the 
postcondition. 

Figure  9  shows  the  original  Ada_ 
Radius  specification  and  body.  Note  the 
parenthesis  on  line  14  of  Figure  9  for  the 
call  to  Ada_Tangent.  The  postcondition 
formula  on  line  7  includes  parentheses 
around  the  Angle  variable,  but  the  code 
implementation  does  not.  This  is  a  simple 
error  in  parentheses.  This  error  is  discov¬ 
ered  during  development  because  the  ver¬ 
ification  condition  for  Ada_Radius  cannot 
be  proven  to  be  correct.  SPARK  has 
found  an  error  during  the  development 
phase  where  it  can  easily  be  fixed.  Had  the 
error  not  been  found  until  the  testing  or 
implementation  phase,  it  would  have 
proven  more  costly.  This  simple  example 
illustrates  how  SPARK  reduces  the  cost  of 
software  development  by  finding  errors 
during  the  development  phase. 

Figure  10  shows  the  corrected 
Ada_Radius  code.  The  parentheses  have 
been  correctly  placed  around  the  Angle 
variable.  Now  when  the  program  devel¬ 
opment  team  executes  the  SPARK  tools 
on  the  code,  a  proof  can  be  built  that 
shows  the  verification  condition  is  true. 
SPARK  is  able  to  automatically  prove  this 
code  is  a  correct  implementation  for  the 
preconditions  and  postconditions. 

This  simple  example  shows  the  power 
of  the  SPARK  correctness  by  construction 
methodology.  Even  on  a  simple  example 
such  as  this,  an  error  in  the  code  was  dis¬ 
covered.  Students  in  a  senior-level  soft¬ 
ware  engineering  course  developed  this 
example  code.  They  eventually  noticed  the 
error  in  their  code  during  testing  and  cor¬ 
rected  it  in  a  later  version.  Had  they  been 
using  the  SPARK  approach  from  the  start, 
they  would  have  found  the  error  while 
constructing  the  code  and  delivered  cor¬ 
rect  code  the  first  time. 

Conclusion 

As  we  have  seen,  the  SPARK  approach  to 
constructing  code  is  a  powerful  way  to 
prove  that  the  code  being  developed  is  a 
correct  implementation  given  the  precon¬ 
ditions  and  postconditions.  This  approach 
is  now  being  used  to  develop  safety  critical 
flight  control  software  for  UAVs  at  the  U.S. 
Air  Force  Academy  as  part  of  a  UAVSAT 
that  is  designed  to  enhance  a  commander’s 


--  function  to  calculate  the  radius  in  Ada 
function  Ada_Radius  { 

Height  :  in  Float; 

Angle  :  in  Float) 
return  Float  is 
begin 

return  (Height  /  Ada_Tangent { (3 . 14159/180 . 0) )  *  Angle); 
end  Ada_Radius ; 

Figure  7:  ^odj  of  Ada Radm 

function_ada_radius_3 . 

HI:  height  >=  0  . 

H2 :  angle  <>  0  . 

H3:  ada_tangent (314159  /  100000  /  180)  <>  0  . 

-  > 

Cl:  angle  *  (height  /  ada_tangent (314159  /  18000000))  = 

height  /  ada_tangent (angle  *  (314159  /  18000000))  . 


Figure  8:  Results  of  Simplification  for  Ada Radius 


ability  to  respond  to  dynamic  situations 
effectively.  The  added  benefit  of  using  the 
SPARK  approach  to  software  develop¬ 
ment  is  that  it  helps  assure  the  system  is 
correct  by  construction.  ♦ 
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Figure  9:  Original  Ada_Kadms  Specification  and  Body 

1  --  function  to  calculate  the  radius  in  Ada 

2  function  Ada_Radius  ( 

3  Height  :  in  Float; 

4  Angle  :  in  Float) 

5  return  Float; 

6  --#  pre  (Height  >=  0.0)  and  (Angle  /=  0.0) ; 

7  --#  return  (Height/Ada_Tangent ( (3 . 14159/180 . 0)  *  Angle)); 

8  --  function  to  calculate  the  radius  in  Ada 

9  function  Ada_Radius  ( 

10  Height  :  in  Float; 

11  Angle  :  in  Float) 

12  return  Float  is 

13  begin 

14  return  (Height  /  Ada_Tangent ( (3 . 14159/180 . 0) )  *  Angle); 

15  end  Ada_Radius; 


Figure  10:  Corrected  Ada_Radius  Code 

--  function  to  calculate  the  radius  in  Ada 
function  Ada_Radius  ( 

Height  :  in  Float; 

Angle  :  in  Float) 
return  Float  is 
begin 

return  (Height  /  Ada_Tangent ( (3 . 14159/180 . 0 )  *  Angle)); 
end  Ada_Radius ; 
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